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IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

In re PATENT application of ) 

Adam RAFF ) 

Application No. 1 0/5 1 7,44 1 ) Group Art Unit: 2617 

Filed: July 21, 2005 ) Examiner: Jaime M. Holliday 

Confirmation No. 2561 ) 

For: Communications Device and ) 

Method Comprising User ) 

Profiles Matching Between ) 

Compatible Devices ) March 20, 2007 



REQUEST FOR RECONSIDERATION 

United States Patent and Trademark Office 
Customer Service Window, Mail Stop RCE 
Randolph Building 
401 Dulany Street 
Alexandria, VA 22314 

Sir: 

A Request for Continued Examination, and the following Request for 
Reconsideration are submitted to be fully responsive to the Office Action of 
September 20, 2006, and the Advisory Action mailed March 6, 2007. Reconsideration 
of this application in light of the comments below and the allowance of this 
application are respectfully requested. Claims 1-66, 68-132, 134 and 135 are still 
pending in the present application and are believed to be in proper condition for 
allowance. 

Initially, the Applicant acknowledge with appreciation, the Supervisory Patent 
Examiner Joseph Feild's clarification of the Advisory Action during a teleconference 
with the undersigned Applicant's representative on March 12, 2007, in view of the 
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unavailability of Examiner Holliday. During the teleconference, the Applicants were 
advised that the previously submitted Amendment After Final has been entered. In 
addition, the claimed invention and the pending Office Action were briefly discussed. 
Per SPE Field's suggestion, the present RCE and Request for Reconsideration are 
being submitted for further consideration. 

Referring to the previous substantive Office Action, the Examiner maintained 
her rejections of the remaining pending claims as being anticipated by U.S. Patent No. 
6,690,918 to Evans et al., or being obvious in further view of U.S. Publication 
2004/0203363 to Carlton et aL, U.S. Patent No. 6,968,179 to De Vries, and/or U.S. 
Patent No. 6,549,768 to Fraccaroli. 

In particular, the Examiner rejected claims 1-3, 12, 13, 21, 28-30, 34, 38, 39, 
48-51, 53-59, 66 and 68-69, 78, 79, 87, 94-96, 100, 104, 105, 114-117, 119-125 and 
132 under 35 U.S.C. 102(e) as being anticipated by Evans. As explained below, this 
rejection is improper in that Evans fails to disclose a device that "does not need to 
receive information relating to attributes of the said compatible device, in order to 
register a match with the said compatible device" as specifically recited in 
independent claims 1 and 68 of the present application. 

In particular, independent claim 1 defines a communications device comprising 
a memory adapted to store at least one profile of a user in the device that contains 
predetermined attributes and requirements of the user. Independent claim 68 is 
similar to claim 1 but recites a communications method. As clearly described in the 
present application, "attributes" are personal data of the user and contain certain 
characteristics of the user such as the user's age, height, hair color, education etc. The 
"requirements" are the user's search criteria and define which attributes relating to 
other users of compatible devices that the user of the device is seeking. It is not 
necessary to safeguard the security of the requirements to the same degree as the 
attributes, as the search criteria of a user do not identify the user themselves. For 
example, if someone intercepted a set of requirements that a user wants in a romantic 
partner, these requirements could not be linked to the user. However, user's attributes 
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such as age, height, hair color, education etc., could be linked to a specific user, 
especially if only a small number of users are in range of the device. 

In the present invention, a device receives requirements (i.e. search criteria) 
from a compatible device, and then compares these requirements against stored 
attributes (personal data of the user of the device). When the locally stored attributes 
match the transmitted requirements of a compatible device, a match signal is 
transmitted. All that is shared is the search criteria (requirements). As a result, the 
private data of the user (attributes) is not required to be shared during the matching 
process. Correspondingly, independent claims 1 and 68 expressly recites that the 
device does not need to receive attributes of the compatible device in order to register 
a match. The personal data of a user of a device is never revealed to any other device 
during the matching process. Instead, a match signal is transmitted based on receiving 
of requirements of a compatible device without requiring receipt of the attributes of 
the compatible device as claimed. Therefore, the present invention defines a 
communications device in which the personal data of the user (attributes) are kept 
private. It will be appreciated that a device that transmits the search criteria of a user 
is more secure in maintaining privacy than a device that transmits personal data 
relating to the user (attributes) and search criteria. 

Alternatively, the personal data of a user may be very large, for example in an 
application in which the device of claims 1 and 68 belongs to a real estate agent and 
holds literally hundreds of properties that are on the real estate agents books. In such 
circumstances, it would involve an extremely large amount of bandwidth of a wireless 
communication channel for the real estate agent device to send details of all their 
properties to a user of a compatible device. 

The cited Evans reference discloses a system in which devices can 
communicate over a wireless network. As recognized by the Examiner at page 4, 
paragraph 1 of the Office Action, Evans discloses that the devices stores "real 
profiles" and "request profiles" of the user. In this regard, Evans discloses "the two 
separate types of profiles, real and request profiles, are created by users practicing the 
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present invention. The inventor terms the profiles 'self (real) profiles and 'meet' 
(request) profiles." (See Col. 6, lines 5-8). Furthermore, Evans also discloses "in the 
above-described example wherein LAN 40 exists at a popular nightclub, for example, 
real (self) and request (meet) profiles reflect personal data such as appearance, 
interests, hobbies, income, marital status, and may include temporary information 
such as purpose for attending the nightclub. A request profile would essentially carry 
the same type of information. A request profile reflects a user's desired attributes in 
someone with whom they might consider socializing." (See Col 8, lines 4-12). The 
above passages provide a very clear teaching that the "real" profiles in Evans reflect 
personal data of the user, and that "request" profiles reflect a user's desired attributes 
in another user. Therefore, the "real" profiles in Evans are equivalent to the 
"attributes" recited in claims 1 and 68 of the present application, while the "request" 
profiles in Evans are equivalent to the "requirements" recited in claims 1 and 68. 

However, in contrast to the present claims, in each of the example 
embodiments disclosed in Evans, the real profiles (attributes) are transmitted in order 
to establish a match. In the first example of Evans shown in Figure 1, a system is 
disclosed in which there are a number of users and a central server 29. It is disclosed 
that the users provide the server with their real (attributes) and request (requirements) 
profiles. In particular, Evans discloses "software (not shown) provided to reside in 
server 29 and within repository 31 functions to match stored 'real' profiles against 
'request' profiles and propagates selected profiles or notice thereof to participating 
and requesting devices using a networking protocol." (See Col. 6, lines 1 to 8). 
Therefore, in contrast to the present invention of claims 1 and 68, the arrangement in 
Figure 1 of Evens has a central server to which each user provides their profiles, and 
does not disclose a controller in a user device that is adapted to register a match 
between the device and a compatible device, in which the controller matches received 
requirements against locally stored attributes. 

In addition, this arrangement discloses an arrangement in which the attributes 
of a user ("real" profile) are transmitted to a central server. As disclosed in Evans, "an 
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important goal of the present invention is to provide users with an ability to 'see' 
pertinent profiles (real) attributed to any other users before initiating committed 
contact in a way that enables quick contact and fulfills a variety of user interests." 
(See Col. 6, lines 13-17). Hence, an important goal in Evans is the sharing of 
attributes between users before initiating committed contact. This is opposite to the 
goal of the presently claimed invention where attributes are not shared in the matching 
process. 

In a second example embodiment, Evans discloses a nightclub with a LAN 40 
where "when one user comes into range of another, each device will send a real 
profile to the other device. These profiles are received by each participating device 
and matched against request profiles (what users are looking for) stored on each 
device. If a match, or in some embodiments, a partial match occurs, the device 
making the match beeps, vibrates, or alerts the user in some other fashion. The 
matching profile is displayed on the device with an option to contact the device that 
sent the matching profile. Contact may be similar to a page, or may be enhanced with 
voice communication capability in some embodiments." (See Col. 6, lines 43-53, 
emphasis added). Hence, this disclosed embodiment does not rely on a central server. 
However, the devices of each user are required to transmit attributes (real profiles) 
which are matched against stored requirements in order to establish a match. Again, 
this is in contrast to the communications device recited in claims 1 and 68 of the 
present application. 

Another disclosed embodiment of Evans uses a combination of hand-held 
devices and a central server 29. It is disclosed that profiles can be uploaded by the 
devices to the server, and that devices can browse the profiles of other users on the 
server. In particular, Evans discloses that "[i]f interested, user 2 may download real 
profiles for matching with his or her request profile stored locally on PC 17. In 
another embodiment, user 2 may upload a request profile to server 29 and have it 
matched with real profiles stored in repository 3 1 . In either case, if there are matches, 
user 2 may decide to travel to the popular nightclub with a Bluetooth(TM) enabled 



10356981.1 



-6- 



Application No. 1 0/5 1 7,44 1 
Docket No. 742408-3 



device similar to any of those illustrated within LAN 40. Alternatively, user 2 may 
select to send a notice and real profile to the owner of a device whose profile matched 
the request profile of user 2. In this case, remote communication may be established 
between user 2 and a user operating either device 43 or device 33 within LAN 40. 
User 1 has the same capability as described with respect to user 2." (See Col. 7, lines 
40-53). 

In view of the above, it should be clear that the cited Evans reference discloses 

that: 

1. a user downloads uploaded real profiles of other users for matching with his 
or her request profile stored locally; 

2. a user may upload a request profile to the server and have it matched with 
real profiles uploaded in a repository; or 

3. a user sends a real profile to another user whose profile matched the request 
profile of the user. 

None of these embodiments of Evans disclose a communications device that 
receives requirements, and matches these against locally stored attributes, while not 
requiring receiving of information relating to attributes in order to register a match as 
specifically recited in independent claims 1 and 68. The remaining passages of Evans 
disclose more detail of the matching process, but the basic operation is as described 
above. 

As discussed above, a very important feature of the present invention as recited 
in independent claims 1 and 68 is that the device sends its requirements, but does not 
need to receive attributes ("real" profiles as referred to in Evans) of compatible 
devices during the matching process. Therefore, the attributes do not need to be sent 
by either device during the matching process, and are always stored locally. The 
Examiner further responded to the previously submitted remarks of the Applicant 
arguing that this feature is disclosed in Col. 7, lines 53-44 of Evans. In particular, the 
Examiner states that "Evans et al clearly discloses 'all real identification information 
such as names, phone numbers and the like are not provided during initial exchange in 
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order to protect anonymity and privacy of users.'" (Citing Evans et al., Col. 7, lines 
53-55). 

However, this quotation is cited by the Examiner out of context. This portion 
of Evans merely suggests keeping private, certain information, including names and 
phone numbers, but still discloses transmitting of other real profile information 
(attributes') before a match is determined. In this regard, the portion of Evans from 
which the Examiner cites further teaches that "[i]f interested, user 2 may download 
real profiles for matching with his or her request profile stored locally on PC 17. In 
another embodiment, user 2 may upload a request profile to server 29 and have it 
matched with real profiles stored in repository 31. In either case, if there are matches, 
user 2 may decide to travel to the popular nightclub with a Bluetooth(TM) enabled 
device similar to any of those illustrated within LAN 40. Alternatively, user 2 may 
select to send a notice and real profile to the owner of a device whose profile matched 
the request profile of user 2. In this case, remote communication may be established 
between user 2 and a user operating either device 43 or device 33 within LAN 40. 
User 1 has the same capability as described with respect to user 2. It is important to 
note herein that all real identification information such as names, phone numbers and 
the like are not provided during initial exchange in order to protect anonymity and 
privacy of users" (See Col. 7, lines 40-56, emphasis added). 

The above full passage indicates that the user 2 uploads a request profile to the 
central server 29 to have it matched with real profiles stored in repository 3 1 . If there 
is a match between the real profile of the owner of another device and the request 
profile of user 2, then user 2 will send his real profile (i.e. attributes) to the owner of 
the other compatible device. Thus, when the context of the Examiner's quotation is 
considered, the Evans reference merely discloses keeping certain information private, 
but still requires providing of other personal information (real profiles or attributes) in 
order to provide a match. 

Therefore, there is no teaching or suggestion of a device that matches the 
requirements (request profiles) received with locally stored attributes (real profiles) 
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without requiring receipt of attributes from a compatible device. As explained, the 
"other device" is required to send (to the central server or the compatible device), its 
real profile (attributes), and after that, user 2 is required to send his attributes to the 
"other device". Therefore, the matching process clearly requires the receipt of 
attributes. 

In view of the above, the Applicant contend that the Examiner has failed to 
properly establish anticipation of the pending independent claims 1 and 68 in that 
Evans fails to disclose every recited limitations of claims 1 and 68. The arguments set 
forth above was previously submitted in response to the prior Office Action, and thus, 
is not believed to raise any new issues. Thus, the withdrawal of the 35 U.S.C. 102 
rejection, and the allowance of claims 1-3, 12, 13, 21, 28-30, 34, 38, 39, 48-51, 53-59, 
66 and 68-69, 78, 79, 87, 94-96, 100, 104, 105, 114-117, 119-125 and 132 is 
respectfully requested. 

Referring again to the prior substantive Office Action, the Examiner rejected 
the remaining dependent claims under 35 U.S.C. 103(a) as being unpatentable over 
Evans in view of Carlton et al., De Vries, and/or Fraccaroli. However, this rejection is 
believed to be improper in that these secondary references fail to cure the deficiencies 
of the primary Evans reference discussed above in that they, fail to disclose or teach a 
device that "does not need to receive information relating to attributes of the said 
compatible device, in order to register a match with the said compatible device" as 
specifically recited in independent claims 1 and 68. Thus, even if the references were 
combined in the manner suggested by the Examiner, they still fail to teach or 
otherwise suggest the present invention as claimed in independent claims 1 and 68 
upon which all of these dependent claims ultimately depend. Correspondingly, the 
Applicant respectfully contend that the Examiner has failed to properly establish a 
prima facie case of obviousness, and requests the withdrawal of these rejections, and 
the allowance of these dependent claims. 
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In view of the foregoing, it is submitted that the present application is in 
condition for allowance and a notice to that effect is respectfully requested. However, 
if any issue remains after considering this response, the Examiner is invited to call the 
undersigned to expedite the prosecution and work out any such issue by telephone. 



NIXON PEABODY LLP 
401 9th Street, N.W., Suite 900 
Washington, D.C. 20004-2128 
(202) 585-8000 
(202) 585-8080 (Fax) 
Customer No. 22204 

Dated: March 20, 2007 



Respectfully submitted, 




Daniel S. Song 
Registration No. 43,143 
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